Interactive patient communication development system for reporting on patient healthcare management

ABSTRACT

A modular interactive system and method for customizing health education to an individual at a remote terminal to induce a modification in a health-related behavior of the individual. The automated system includes a questionnaire generator for questioning the individual to determine his or her motivational drivers and comprehension capacity. The questionnaire generator is a graphical user interface that allows a clinician to graphically attach questions to answer to action. A processor then generates a script program based on what the clinician has attached together. A profile generator receives answers entered by the individual from the remote terminal and generates a motivational driver profile and a comprehension capacity profile of the individual. A translator receives clinical data relating to a current health condition of the individual and translates the clinical data, the motivational driver profile, and the comprehension capacity profile into a profile code. An educational fulfillment bank matches the profile code to matching educational materials and transfers the matched educational materials to the remote terminal. An evaluation program evaluates educational responses of the individual and provides profile updates for targeting subsequent educational material to the individual based on the educational responses.

CROSS-REFERENCE TO RELATED APPLICATIONS

This is a continuation of co-pending application Ser. No. 09/810,334,filed Mar. 14, 2001, which is herein incorporated by reference.

FIELD OF THE INVENTION

The present invention relates generally to a modular interactivedevelopment system and method for reporting on patient management, andin particular to an automated content delivery program able to connectremote users across independent platforms to a central database oflibraries whereby a patient's health can be scored dynamically.

BACKGROUND OF THE INVENTION

This invention relates to the field of health management, particularlyto an automated interactive system and method for reducing the riskassociated with a monitored client.

For example, the know art includes a number of health-management systemsfor providing outpatient services to patients with chronic healthconditions such as asthma and diabetes. However, these systems areincapable of administering a treatment protocol responsive to thepatient's current profile and of updating the profile in response to theadministered protocol.

SUMMARY OF THE INVENTION

This invention presents a flexible and scalable system in contentdevelopment for patient management healthcare. Due to the modular objectoriented-structure, individual content modules (“dialogs”) can be mixedinto an unlimited number of undatable customized programs, addressingindividual as well as co-existing disease states (“co-morbid”) in anycombinations, and with automated content variation for improved patientcompliance. A dialog is the smallest content object in the FlexCubecontent structure. Its content addresses issues related to a unique setof symptoms, behaviors or knowledge related to a specific aspect ofmanaging a certain disease referred to as an aspect of care.

In its basic format, each dialog contains questions related to signs andsymptoms, behaviors and knowledge with answers categorized as high,medium or low risk answers. For each answer there is a relevant followup, which can be a teaching statement, an acknowledgment, a motivationalstatement or a new question that will explore the patient's condition inmore depth. While the logical branching within a dialog is driven bypatient answers, no dependency exists between individual dialogs.

Dialogs are located in a common pool organized by library. From thislibrary each individual dialog is referenced for participation(appearance) in programs and daily sessions. A dialog's behavior in aprogram (schedule, position, reporting) is defined at the time of thedialog creation or it is custom defined during the program contentselection process. In this way dialogs maintain their integrity whilebeing used and re-used in several client programs. They combine freelywith other dialogs in user defined program selections, allowing anunlimited combination of aspects of care and co-existing diseases.Finally, they are easily accessible for revisions and updates.

The present invention provides an object-oriented dialog and modulartoolkit structure that enhances quality control options. Also includedare the centrally located content objects that offer overview andtracking of the currently active content, global error correction andglobal update of content to current standards of care. Because thepresent invention splits up interfaces for content creation and contentselection into separate modules, the present invention exercises controlover customer's access to content development in compliance with currentand future Federal Drug Administration labeling. Finally the system'sstructure limits logical branching errors to within a dialog, therebyoffering a more robust and less error prone system overall.

Since the content of a dialog and the output of a dialog is related andmapped to a specific aspect of care, the user will have the power andflexibility to model risk evaluation and outcomes reporting aroundcustom selected aspects of care.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and many of the attendant advantages of thisinvention will become more readily appreciated as the same becomesbetter understood by reference to the following detailed description,when taken in conjunction with the accompanying drawings, wherein:

FIG. 1 is a block diagram depicting a system's compositional andreferenced components;

FIG. 2 is a flow chart diagram depicting the overview of dialogcreation;

FIG. 3 is a block diagram depicting an interdependent characteristics(operators) of a dialog;

FIG. 4 is flow chart depicting the steps in creating and storing ofcontent data from a dialog;

FIG. 5 is a flow chart diagram depicting the creation of the programmingstatements using a Dialog Editor Platform;

FIG. 6 is a block diagram illustrating the three dimensional aspects ofthe dynamically determined risk state output scale;

FIG. 7 is a flowchart depicting the creation of programs using a ProgramComposer User Interface;

FIG. 8 is a flow chart depicting a Linker User Interface; and

FIG. 9 is a flow chart depicting a Reporter User Interface.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENT

The present invention includes an object-oriented content structure inwhich the smallest content object, a care specific dialog, is located ina central library from where its characteristics (operators) arecomposed and referenced by a modular set of tools located at a clientcomputer.

FIG. 1 is a block diagram depicting a system 10's compositional andreferenced components. Compositionally, the system 10 relies on foursystem components for dialog or program creation. Additionally, FIG. 1illustrates two other system components that interact with thereferenced components of the system. A dialog Composer 20, furtherreferenced in FIG. 2, which is used to author dialog content by anaspect of care. A Program Composer 30, further referenced in FIG. 7, isa user interfaced click and drag assembly platform for composingprograms (a virtual content defined collection of dialogs). On acomputer desktop, content dialogs are selected (referenced) for use indisease/client specific programs, with program specific tagging ofindividual dialog attributes related to frequency (scheduling) andreporting. A Program Patient Linker 40 is a user interface integratedinto the desktop on which patients are assigned to programs. During theassignment process patient identification and patient specific metricsare added to the program. A Care Reporter 50, further referenced in FIG.9, is a user interface for easy patient result lookup, triage and trendreports. Reporting requirements set in the Program Composer 30 determinewhich reports are displayed.

Compositional elements of the system 10 reference either one or both ofthe two remaining components of the system depicted in FIG. 1. A ProgramScheduler 60, further referenced in FIG. 8, is an engine for automatedscheduling of dialogs based on attributes set in the Program Composer30, and A Dialog Library 70. The Dialog Library is the principal centrallocation of dialog content units. Dialogs are organized into body systemlabeled sub-libraries and stored within the Dialog Library 70.

The structure of the system is developed from the integration of thefour compositional components as referenced above with the tworeferenced components and begins with the creation of dialogs in theDialog Composer 20 as depicted FIG. 2.

FIG. 2 is a flow chart diagram depicting the overview of dialog creationand is referenced with more particularity in FIG. 4. Referring to FIG.2, a patient 100 reports on a specific aspect of care 110 (i.e., footcare in a Diabetes Structure) that is addressed by a-dialog 125, thesmallest content structure of the system, from a disease specificlibrary 120. The basic format of each dialog includes questions 130related to patient self-management behaviors 132, patient-reportablesymptoms 134, or patient knowledge 136. Each question provides a choicefor an answer (“output variable”) 140 that falls into one of three riskcategories; high 142 medium 144 and low risk 146. For each risk categorythere is an associated follow up 150 which is a teaching statement 152,a motivational statement 154 or a new question 156 that explores thepatient's condition in more depth.

While the logical branching within a dialog depends on output variables,no dependency exists between individual dialogs. Dependencies fordialogs exist outside the dialog structure in related operators.

FIG. 3 is a block diagram depicting the interdependent characteristics(operators) of a dialog 300 in the system matrix. The interdependentcharacteristics include a Name Label 310 for the aspect of careaddressed, a Library 320 that houses a body system specific Localization325, client specific Programs 330 in which the dialog is being used(referenced), a Schedule frequency 340 by which the dialog is beingdisplayed to a patient in a specific program, definition of Reportingrequirements 350, and Patient Identification information 360 and metricsof each individual appliance to which the dialog is assigned.

The user interface is easy to use due to the simplicity of programstructure in which the user is able to interface with the program anddialog composition aspects of the system. Simply using drag and dropcontent selection procedures based on a medical decision creates aprocess familiar to the user. The user decides what aspects of care arerelevant for a given program or for an individual patient and in mostcases simply selects existing content based on that decision. In allsteps of dialog composition, certain steps are taken to make availablethe dialog in a content library.

FIG. 4 is a flow chart depicting the steps in creating and storing ofcontent data from a dialog, a user's first task is to name thedialog-to-be-created as depicted in block 400. Next, the user definesthe library section of block 410, in which the dialog will reside. Theuser then identifies an aspect of care at block 420 to which the dialogwill primarily refer. Once the naming conventions are assigned and theaspect of care is chosen, the user creates dialog programming statementsat block 430, in a graphical programming environment as embodied in FIG.5. New dialog content is then stored in an appropriate user library atblock 440.

The user who has access to create new content does so using a simpledialog composer as embodied in FIG. 5. FIG. 5 is a diagram depicting thecreation components of a dialog Editor Platform. First, a user ispresented with a palette 500 of programming statements that arerepresented as graphic symbols (icons) that can be dragged from thepalette of available statements into a dialog construction platform 505.In a typical embodiment of the present invention, the user drags a startquestion icon 510 and a three pronged answer icon 520 from an iconpalette down to the construction platform 500. The user then activates adialog box for each icon by clicking on it with a mouse and specifying aquestion associated with that particular icon, for example, a StartQuestion Dialog 515. Next, in an Answer Dialog 524, the user entersthree answer options relative to the start question and assigns a rawrisk value to each answer 526. The risk values are assigned from high tolow with a corresponding text answer. “Yes” equals low risk and “no”equals high risk and “medium” equals somewhere in the middle of low andhigh risk. Follow up questions icons 530 are dragged onto theconstruction platform along with an associated answer icon 540. Ananswer dialog 545 is then prepared. Clicking on the output icon 550, theuser activates the output dialog box 555. Here the user defines riskstate output 558 in detail, further depicted with more particularity inFIG. 5, defining the position of the answer relative to the axis of therisk cube. At any time during or after the dialog creation process, theuser can review the dialog created, using a simulation interface to anappropriate appliance or in the alternative, the user can review theactual dialog content in a text only overview window. Once all thefollow up questions, answers and output dialogs are formulated and putonto the construction platform 525, the newly created dialogs are storein a user library 560 from where it can be referenced for participationin any user defined care management program or for later updating orediting.

FIG. 6 is a block diagram illustrating the three dimensional aspects ofthe dynamically determined risk state output scale which in the DialogComposer, FIG. 5, is referenced at block 558. The X-axis 610 scaleswhether the answer to a question dialog sets the risk at a certain risklevel on a 9 point risk scale or whether the answer moves the patientrisk state in a certain direction and by how much, thereby creating anaccumulated risk profile. Additionally, the answer to a dialog isincorporated as a value in a mathematically calculated risk state thatmay incorporate other answers as well, creating a composite, weightedrisk state. The Y-axis 620 refers to the actual aspect of care in whichthe risk will be incorporated. The Z-axis 630 incorporates theexpression of risk 530, i.e, whether the risk is assigned to a sign orsymptom 632, a behavior 634, or a knowledge expression 636. This dynamicmodel allows for very sophisticated risk profiling including risk trendalerts, composite risk profiling by aspects of care and profiling byrisk expression. The dynamic risk “foot prints” available at any timecan serve as triggers for automated content selection.

Once dialogs are named, created and assigned to an aspect of care andthe risk output is assigned to the appropriate dialog, a user of thesystem can then use the Program Composer 30 to create the program thateventually is assigned to a patient.

FIG. 7 is a flowchart depicting the creation of “programs” using theProgram Composer User Interface (“UI”) . The UI is a platform forselecting library resident Dialogs created as depicted in FIG. 6, forparticipation in user-defined care management programs. In a typicalembodiment of the present invention, the first step is to name thefuture program block 700. Next, at block 710, a user selects the diseaselibraries from which the program dialogs are created. Simultaneously, atblock 720, the user checks the Utilities Library to add dialogs to theprogram that are not disease specific like generic greetings. This givesthe user access to the detailed content of both of these librariesorganized by aspects of care and their respective dialogs. Creating theprogram is now a simple task of adding dialogs to the program list, seeblock 730, and at block 740 to define the delivery of the dialogs as auser can choose specific delivery of the dialogs on a daily 750, weekly752, or any other 754 programmed timed basis. Additionally, at block742, a user checks the priority of dialogs to set parameters necessaryfor the correct scheduling of the dialogs in the program. Options are toforce the scheduler to include the dialog block 744, or to assigndialogs as fillers, block 746. The later could be the case, for example,with trivia type dialogs, entertainment dialogs etc. Also, the user hasthe opportunity to decide the placement of dialogs in daily sessions.Greetings, for example, should be checked as “always first.” The usercan review the complete created program using the “View Selection” link,block 760. Using a very simple interface, the user has now created atotally custom made program. At block 770, the program is now availablefor assignment to any of the user's patients or for later modificationby the user by adding or deleting dialogs. The present inventionembodies the assignment by way of a Linker User Interface (“Linker UI”)as depicted in FIG. 8.

FIG. 8 is a flow chart depicting the Linker UI, which is a platform forassigning or “linking” care management programs to patient populationsor to individual patients. The first step at block 800 is to retrievepatient's name(s) to be used on the work platform through a filtering orsorting procedure defined by the user. Next, at block 810, the usermarks the patient(s) and the care management program to be assigned.Finally the user creates the “Link” to activate a dialog box that allowsthe user to specify a time frame in which the program will run for theselected patient(s), block 820. Should the user wish to link the patientto other programs all that is needed is to repeat the process. Toprocess the linking of an entire population or part of a population auser selects all patients, block 800, and assigns all of them, block810, to a program.

The last step in the creation of a system program is the creation of aReporter User Interface (“Reporter UI”) which creates patient reportsspecific to patient results that in turn can initiate program actionsbased on those results. FIG. 9 is a flow chart depicting the Reporter UIand the creation of reports. The layout of the Reporter UI is completelyconsistent with that of the Linker UI depicted in FIG. 8. First a userretrieves patient names through a filtering process, block 902. The userfilters, at block 900, names through the programs by either risk search,block 904, the aspects of care, block 905, within each program, or therisk expression, block 906, as defined as a symptom, behavior orknowledge, block 908, factor. This is done to allow a user to trend arisk profile, block 910, for the patient in the aspect of care where thepatient has scored, for example, a high-risk profile as depicted in FIG.6. A user can configure the Reporter UI to display block 920 the actualanswers or results that led to the exampled high-risk profile. Lastly,at block 930, a patient is assigned to a program based on the riskprofile or Aspect of Care. Reports assigned to patients can now forexample, allow the user to see details for each aspect of care, order areport printed or write a note that will be associated with a linkedevent.

While this invention has been described in terms of several preferredembodiments, there are alterations, permutations, and equivalents thatfall within the scope of this invention. It is therefore intended thatthe following appended claims be interpreted as including all suchalterations, permutations, and equivalents as fall within the truespirit and scope of the present invention.

1. A method for managing a condition of an individual, comprising thesteps of: (A) selecting a plurality of dialogs from one or morelibraries; (B) assembling said dialogs; and (C) defining a deliveryschedule for said dialogs as assembled to one or more of saidindividuals.
 2. The method according to claim 1, wherein said dialogscomprise a plurality of content objects.
 3. The method according toclaim 1, further comprising the step of: generating a prioritization forsaid dialogs.
 4. The method according to claim 3, wherein saidprioritization comprises an option to include said dialogs in saiddelivery schedule.
 5. The method according to claim 3, wherein saidprioritization comprises an option to include one or more filler typesof said dialogs in said delivery schedule.
 6. The method according toclaim 1, wherein said delivery schedule comprises (i) a daily schedule,(ii) a weekly schedule or (iii) a custom schedule.
 7. The methodaccording to claim 1, further comprising the step of: generating apresentation defined by said dialogs as assembled.
 8. The methodaccording to claim 1, further comprising the steps of: generating one ormore management programs for said dialogs related to said condition;marking a particular individual among a plurality of said individualsfor an assignment; and linking said particular individual with saidmanagement programs per said assignment.
 9. The method according toclaim 1, further comprising the steps of: identifying a particularindividual among a plurality of said individuals by filtering saidindividuals using at least one of a plurality of factors for saidcondition; generating a profile for said particular individual based ona plurality of responses received from said particular individualresponding to a plurality of questions sent to said particularindividual; and generating a report for said profile.
 10. The methodaccording to claim 1, wherein said management of said conditioncomprises a disease management, said one or more libraries comprise oneor more of (i) a disease specific library and (ii) a non-diseasespecific library and said dialogs concern a plurality of aspects ofhealth care.
 11. The method according to claim 1, further comprising astorage medium storing a computer program comprising the steps ofclaim
 1. 12. A method for managing a condition, comprising the steps of:(A) generating one or more management programs for a plurality ofdialogs related to said condition; (B) marking a particular individualamong a plurality of individuals for an assignment; and (C) linking saidparticular individual with said management programs per said assignment.13. The method according to claim 12, further comprising the step of:generating a time frame in which said management programs will run forsaid particular individual.
 14. The method according to claim 12,further comprising the step of: identifying said particular individualby filtering a plurality of names of said individuals.
 15. The methodaccording to claim 12, wherein said management of said conditioncomprises a disease management and said management programs concern aplurality of aspects of health care.
 16. The method according to claim12, further comprising a storage medium storing a computer programcomprising the steps of claim
 12. 17. A method for managing a condition,comprising the steps of: (A) identifying a particular individual among aplurality of individuals by filtering said individuals using at leastone of a plurality of factors for said condition; (B) generating aprofile for said particular individual based on a plurality of responsesreceived from said particular individual responding to a plurality ofquestions sent to said particular individual; and (C) generating areport for said profile.
 18. The method according to claim 17 whereinsaid report comprises said responses and is readable by a human.
 19. Themethod according to claim 17, wherein said factors comprise at least oneamong (i) a plurality of factors related to a level at risk (ii) aplurality of factors related to an aspect of care and (iii) a pluralityof factors related to an expression of risk.
 20. The method according toclaim 19, wherein said factors related to said expression of riskcomprises at least one among (i) a plurality of symptom factorsreportable by said individuals, (ii) a plurality of behavior factors ofsaid individuals and (iii) a plurality of knowledge factors of saidindividuals.
 21. The method according to claim 17, further comprisingthe step of: assigning said particular individual to a healthcareprogram based on said report, wherein said management of said conditioncomprises a disease management.
 22. The method according to claim 17,further comprising a storage medium storing a computer programcomprising the steps of claim 17.